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and a messaging functionality, said method comprising the steps of receiving a message (MM) for said terminal (MS) by said messaging 
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METHOD FOR DELIVERING MESSAGES 



Field of the Invention 

5 The present invention relates to a method for delivering 
messages in a communication network. 



Related Background Art 



10 The 3 rd Generation Partnership Project (3GPP) currently 
discusses the issue of a multimedia messaging service 
center (MMSC) as a network element in a communication 
network, e.g. for the use in the general packet radio 
system (GPRS) and the universal mobile telecommunications 

15 system (UMTS) . Unfortunately, most of it is still 

undefined, like the management of the capabilities and 
the user profile of the terminal. i 

The functionality of a multimedia messaging service 
20 center, from the technical viewpoint, provides a non- 
realtime service which operates partly in store-and- 
forward fashion. Additionally, multimedia messages are 
sent using the GPRS air interface, for example, and the 
contents of the messages can be text, images, speech, 
25 video clips or the like, or any arbitrary combination of 
these. For example, these contents can be delivered from 
one mobile station to another using this multimedia 
messaging service . 



30 According to the service description of multimedia 

messaging, the content and length of the message is in 
principle unlimited. However, due to the various 
different types of terminals (e.g. mobile terminals), a 
large number of different capabilities of these terminals 

35 is present in the network. Consequently, each of these 
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terminals inevitably causes its own specific restrictions 
and limitations, in particular with respect to the 
possibility of handling a multimedia message. 



5 For example, the available storage capacity is limited 
and may differ between different terminals, and thus, not 
all of the terminals can be able to receive all possible 
contents. Furthermore, the capabilities of a single 
terminal may change dynamically, e.g. if the terminal has 
10 already received and stored a message, the remaining 
memory will be reduced. Similarly, the terminal can be 
connected or disconnected to or from other devices like 
laptops etc. 



15 Moreover, in addition to the limitations caused by the 
terminal capabilities, the users may want to create or 
modify their own user profile, thereby also resulting in 
special restrictions. For example, a user may want to 
have certain types of multimedia messages to be stored in 

20 the multimedia messaging service center, forwarded to an 
internet address or discarded. These user defined 
restrictions can be based for example on the size of the 
multimedia message, the content-type or the sender, 

25 As can be seen from the foregoing, there arises the 

problem, that certain parts of the multimedia message or 
even the whole message may not be managed by the 
recipient terminal due to a lack of capabilities to 
receive, store, process or display the multimedia 

30 message. Consequently, the uncontrolled transmission of 
multimedia messages can cause serious problems up to 
system failures in the terminals which may lead to at 
least a partly breakdown of the terminal functionality, 
thus being off communication. 

35 
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Summary of the Invention 

Therefore, it is an object of the present invention to 
provide a method for delivering messages in a 
5 communication network consisting of at least one terminal 
and a messaging functionality which is free from the 
above drawbacks. 



According to the present invention, this object is 
10 achieved by a method for delivering messages in a 

communication network consisting of at least one terminal 
and a messaging functionality, said method comprising the 
steps of submitting information concerning the 
capabilities of the terminal and a current user profile 
15 thereof from said terminal to said messaging 

functionality upon the occurrence of a predetermined 
condition; deciding by said messaging functionality 
according to said information how to handle a message for 
said terminal received by said messaging functionality; 
20 and handling said message by said messaging functionality 
according to the result of said decision step. 



Furthermore, the object is achieved by a method for 
delivering messages in a communication network consisting 

25 of at least one terminal and a messaging functionality, 
said method comprising the steps of receiving a message 
for said terminal by said messaging functionality; 
sending a notification about the presence of said message 
from said messaging functionality to said terminal; 

30 deciding by said terminal due to its capabilities and 

current user profile how to handle said received message; 
replying by said terminal to the notification sent by 
said messaging functionality, therewith instructing 
according to the result of said decision step; and 
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handling said message by said messaging functionality 
according to said instructions. 

Furthermore, the present invention proposes a messaging 
5 functionality device comprising receiving means adapted 
to receive messages and information; processing means 
adapted to process received information data and 
messages; storing means; sending means adapted to send 
information and messages, respectively, to said terminal. 

10 

Still further, the present invention proposes a terminal 
device comprising receiving means adapted to receive 
messages and information; processing means adapted to 
process received information data and messages; storing 
15 means; sending means adapted to send information and 
messages, respectively, to said terminal. 

Advantageous further developments of the present 
invention are as set out in the respective dependent 
20 claims. 

Hence, it is an advantage of the present invention that 
the handling of the messages is based on the capabilities 
of the recipient terminal and the user profile of the 

25 corresponding subscriber. Accordingly, it is possible to 
correspondingly handle each message and each part of this 
message. In conclusion, failures or functionality 
breakdowns of the terminal are no longer possible and the 
method according to the invention further provides a 

30 large scope for the subscriber for a flexible and free 
participation in the network. 

Preferred embodiments of the present invention are 
described herein below in detail by way of example with 
35 reference to the accompanying drawings. 
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Brief Description of the Drawings 

Fig. 1 shows a schematic diagram of the basic signaling 
5 sequence for transmitting a multimedia message between a 
multimedia messaging service center and a recipient 
terminal according to a first embodiment of the present 
invention; 

10 Fig. 2 shows a flow-chart illustrating an example for the 
functionality implemented at the multimedia messaging 
service center after receiving a new mobile terminated 
multimedia message according to a second embodiment of 
the present invention; and 

15 

Fig. 3 shows another flow-chart illustrating an example 
for the functionality implemented at the terminal after 
receiving an MMSNotify message according to the second 
embodiment of the present invention. 

20 

Description of the Preferred Embodiments 

According to the present invention, a submission of a 
multimedia message as an example for a message to be 

25 delivered in a communication network is handled according 
to capabilities and a user profile of a recipient 
terminal like for example a mobile station. The decision 
how to handle the submission is based on the circumstance 
that content (s) , size and type(s) of the multimedia 

30 message, the capabilities of the terminal, and the user 
profile of a subscriber related to said terminal are 
available to respective decision means. 

A handling of those messages to be delivered will be done 
35 in another element of the communication network, i.e. a 
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network device having a messaging functionality 
implemented. During the following description of the 
preferred embodiments of the invention, the description 
will be made by referring to the example of a multimedia 
5 messaging service center as such a network device having 
implemented the messaging functionality and by referring 
to the example of a multimedia message as a delivered 
message. Nevertheless, it is to be noted that these 
examples are by no way limiting. Namely, also a monomedia 
10 message could be delivered and the message functionality 
need not be implemented in a single network device such 
as a multimedia messaging service center, but can also be 
a distributed functionality. 



15 With respect to the above mentioned decision, for the 
sake of explanation, the multimedia message can be 
regarded as multimedia messaging service center 
originated while the terminal capabilities and the user 
profile can be regarded as being inherent to a respective 

20 terminal. Hence, information has to be transmitted in 
either way to enable a decision. 

Further, for the sake of convenience, it would be 
appropriate if the decision is automated and optimized 
25 depending on the parameters provided by the terminal and 
the user. However, this is not a prerequisite for the 
present invention . 



Since the multimedia message can have a certain format, 
30 multiple parts (segments), different contents (text, 
images, speech, videos, etc.), a different size, or a 
sender identity, it is apparent that it is dependent on 
the capabilities of the recipient terminal and the 
currently defined user profile, whether the terminal is 
35 able to receive, display or process the multimedia 
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message, and further, dependent on whether the subscriber 
wishes to do so. 

Consequently, the result of the decision as to how to 
5 handle the multimedia message can be that it shall be 

delivered completely, in part or modified, that it shall 
be discarded, stored in the multimedia messaging service 
center or forwarded, for example, to an internet email- 
address. As mentioned before, instead of an automated 
10 decision, a request to the user what to do is of course 
also possible, either in general or in special cases. 
Besides, the storage of the multimedia message in the 
multimedia messaging service center will in the most 
cases be limited to a certain time period, since there is 
15 presumably no unlimited memory available in the 

multimedia messaging service center (consequently, the 
MMSC may inform the subscriber by a respective 
notification about the expiry of the time period before 
erasing the stored message) . If the multimedia message 
20 shall only be delivered in part, it is possible that also 
the not delivered parts are stored, forwarded or 
discarded. The case of a modification of the multimedia 
message might usually be the conversion of the multimedia 
message from one format to another, but also a 
25 compression or any other kind of processing the data 

shall be understood by this expression. As a result, a 
multimedia message which is not as such divided into 
parts can be segmented by this processing. With regard to 
the several possibilities of how to handle the submission 
30 of the multimedia message, the result of the decision 
might finally also be a respective combination of the 
items discussed above. 

Apart from that, if the multimedia messaging service 
35 center is designated as a new network element for the 
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general packet radio and universal mobile 
telecommunications systems, the data transmission will 
most likely be performed with protocol data units in non- 
realtime by use of the respective other network elements 
b according to said systems, which other network elements 
are omitted from the description of the present invention 
for the sake of distinctness. 



First Embodiment 



10 



According to a first embodiment of the present invention, 
the decision concerning the selection of the delivery of 
a multimedia message is made in the multimedia messaging 
service center (MMSC) . The basic idea for this approach 

15 resides in the fact that, after a new multimedia message 
has been received, the multimedia messaging service 
center is immediately able to decide which type of 
delivery has to be selected. Stated in other words, the 
multimedia messaging service center acts as a pre-filter 

20 for the terminal. 



To provide such a functionality, the terminal 
capabilities and the current user profile have to be 
stored in the multimedia messaging service center. 

25 Furthermore, this information has to be updated under 
certain conditions. If these information (terminal 
capabilities and user profile) and the imparted 
multimedia messaging service center are never changed at 
all, the information has to be submitted and stored once 

30 and never to be updated. Of course, these prerequisites 
are nearly never met. Hence, the initial information and 
the updates thereof have to be submitted to the 
multimedia messaging service centers in order to keep the 
information stored therein valid. 

35 
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This information can include a display type of said 
terminal, a keyboard type of said terminal, codecs 
supported by said terminal, a memory size of said 
terminal, an electrical connection of said terminal to 
5 other devices, an external accessory attachment to said 
terminal or the like, and of course a current user 
profile . 

There are several possible conditions when to submit the 
10 information from the terminal to the multimedia messaging 
service center and the possibility of updating is not 
limited to only one condition. However, the update should 
be coupled to the necessity to update, or at least to the 
possibility of submitting the information with other data 
15 (this can be any signaling sequence between these two 

network elements) that has to be submitted, in order to 
avoid a cluttering of traffic. Consequently, the 
condition when the terminal starts its signaling sequence 
to submit the information is predetermined. This 
20 condition can be a login of said terminal into said 
network, a change of connection conditions of said 
terminal, a context activation or the change of a context 
condition, a user profile creation or modification, a 
terminal originated traffic or a terminal terminated 
25 traffic, a request of said multimedia messaging service 
center, a notification of said multimedia messaging 
service center concerning the presence and/or the 
contents of a new multimedia message to said terminal, or 
the like. 

30 

With reference to Fig. 1, the signaling sequence for 
submitting the information about the capabilities of the 
terminal and the current user profile is illustrated by 
the example of submitting the information upon the 
35 predetermined condition of context activation. 
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Consequently, in a first step Sll, a terminal MS such as 
a mobile station requests a context activation to the 
multimedia messaging service center MMSC via a support 
5 node SN . With this request for context activation, the 
terminal MS submits simultaneously its capabilities CAP 
and current user profile UP. According to examples of the 
current network being the GPRS or UMTS, the whole 
signaling shown in Fig. 1 can take place by using 
10 protocol data units PDU. 

After this transmission has been completed, the 
multimedia messaging service center MMSC stores the user 
profile UP of the terminal MS. Due to the capabilities of 

15 the multimedia messaging service center, it may be 

possible or necessary to adapt the user profile UP of the 
terminal MS within the range of the capabilities CAP of 
the terminal MS. However, the user may inhibit such 
amendments of his preferred user profile. The storage of 

20 the user profile UP and its eventual processing is done 
in a step S12. 

In a third step S13 at least the acknowledgement of the 
context activation is submitted from the multimedia 
25 messaging service center MMSC to the terminal MS via the 
support node SN . 

However, if a multimedia message MM for the terminal MS 
is currently present in the multimedia messaging service 

30 center MMSC, there will be a step S14 before step S13, 
wherein this multimedia message MM is handled according 
to the user profile UP stored in the multimedia messaging 
service center MMSC. The handling of the multimedia 
message MM corresponds to the result of a decision 

35 process which is based on the capabilities CAP and the 
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user profile UP of the terminal MS which are now stored 
in the multimedia messaging service center MMSC. The 
possible results of this decision process are discussed 
above in detail and it is mentioned again that according 
5 to the first embodiment, this decision is made by the 
multimedia messaging service center MMSC . 



According to the result of this decision, the handling of 
the multimedia message MM may require a processing of the 

10 data of the multimedia message MM (e.g. in the cases of a 
modified or a partly deliverance) or not, as is mentioned 
above. In any case, if at least parts of the multimedia 
message MM have to be submitted to the terminal MS, this 
is done in the step S13 together with the submission of 

15 the context activation acknowledgement. 



As mentioned before, the example depicted in Fig. 1 is 
given by way of illustration only, while the first 
embodiment is not limited thereto. Consequently, a 
20 respective adaptation of the process shown in Fig. 1 to 

the other possibilities according to the first embodiment 
as described above is fully apparent to those skilled in 
the art. 



2 5 Second Embodiment 



Apart from the solution according to the first 
embodiment, there is the alternative to maintain the 
terminal capabilities and user profile information only 
30 at the terminal side and consequently, to take the 

decision concerning the selection of the delivery of a 
multimedia message by the terminal. 



Therefore, the basic idea of the second embodiment 
35 resides in that the terminal capabilities and user 
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profile information is stored in the terminal, e.g. in 
the terminal equipment or, in the case of a mobile 

terminal, in the SIM or in both. Due to this, the 

decision regarding the delivery of a multimedia message 
5 is taken in the terminal. 

The functionality of the multimedia messaging service 
center and of the terminal according to the second 
embodiment are now described with reference to Fig. 2 and 
10 Fig. 3. 

Fig. 2 illustrates an example of the functionality of the 
multimedia messaging service center MMSC according to 
this embodiment upon receipt of a new mobile terminated 

15 multimedia message MM. As can be gathered therefrom, the 
multimedia messaging service center MMSC automatically 
sends a special control message MMSNotify in a step S21 
to the terminal MS after it has received a new multimedia 
message MM (step S20) . The MMSNotify message contains 

20 information about the actual multimedia message MM such 
as the total size of the message, the content (s) , the 
content type(s), a human readable description and so on. 

On the basis of the stored information about the terminal 
25 capabilities CAP and its current user profile UP, the 

terminal MS now processes the information included in the 
MMSNotify message and accordingly decides how to handle 
the multimedia message MM. Based on this decision 
process, the terminal MS sends a corresponding reply 
30 message to the multimedia messaging center MMSC, which is 
received by the multimedia messaging service center MMSC 
in a step S22. This process is illustrated by way of 
example in Fig. 3, which will be described herein below. 
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It is noted that the present invention does not restrict 
the means by which the MMSNotify message is delivered to 
the terminal MS. For example, the multimedia messaging 
service center MMSC could send the MMSNotify message as a 
5 special SMS message, which is then parsed by the terminal 
MS, or the multimedia messaging service center MMSC could 
use a specific bearer (e.g. a control channel) dedicated 
to multimedia messaging service. 

10 Anyway, the signaling sequence according to the second 
embodiment for the exchange of messages and information, 
respectively, is based upon the following principle. Upon 
receipt of the MMSNotify message, the terminal MS submits 
the MMSResultRequest message as a reply, which is 

15 received by the multimedia messaging service center MMSC 
in the step S22. The possible MMSResultRequest messages 
do, however, differ from each other due to the result of 
the decision process. Hence, the MMSResultRequest can be 
a MMSDeliverReq, a MMSStoreReq, a MMSForwardReq or a 

20 MMSDiscardReq, for example. 

Hence, in a step S23, the multimedia messaging service 
center MMSC checks if the reply of the terminal MS is the 
MMSStoreReq message, and in case of "yes", the multimedia 
25 message MM is stored in the multimedia messaging service 
center in a step S26. In case of "no" the process 
proceeds further to the step S24 to check whether the 
reply is the MMSDeliverReq message. 

30 If the MMSDeliverReq message was replied by the terminal 
MS, the process flows to a step S27, wherein the 
multimedia messaging service center MMSC checks the 
MMSDeliverReq message, whether the multimedia message 
shall be delivered partly or completely. The step S29 

35 shown in Fig. 2 represents the case of a partly 
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deliverance of the multimedia message MM to the terminal 
MS, followed by the above mentioned step S26, wherein at 
least the undelivered parts of the multimedia message MM 
are stored in the multimedia messaging service center 
5 MMSC. In contrast thereto does the step S210 represent 
the case of a completely deliverance of the multimedia 
message MM to the multimedia messaging service center 
MMSC, followed by a step S211, wherein the multimedia 
message MM is removed from the multimedia messaging 
10 service center MMSC after the deliverance. 

If the MMSDeliverReq message was not replied by the 
terminal MS, there is checked in a step S25 of the 
process, whether the MMSForwardReq message was replied, 

15 and if not, it is assumed that the MMSDiscardReq message 
is present and the multimedia message MM is removed from 
the multimedia messaging service center MMSC according to 
the step S211. In case the MMSForwardReq message is 
present, the multimedia message MM is first forwarded in 

20 a step S28 to a destination given by the MMSForwardReq 
message, before it is removed from the multimedia 
messaging service center MMSC in the step S211. 

Now the functionality of the terminal MS after receiving 
25 an MMSNotify message in a step S30 according to the step 
S21 of Fig. 2 is described with reference to Fig. 3. 

Specifically, the terminal MS checks its capabilities CAP 
and user profile UP in a step S31, followed by the 

30 corresponding decision steps S32-S35. As can be seen from 
Fig. 3, the choice to leave the decision to the user is 
included as an option corresponding to the step S32. In 
case the user profile UP is set such that the user shall 
decide on the delivery of a multimedia message MM, the 

35 result of his input is carried further to the steps 
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S33-S35. If the decision is to be done automatically, 
according to the second embodiment of the present 
invention, the terminal MS decides due to its user 
profile UP and capabilities CAP how to handle the 
5 multimedia message MM present in the multimedia messaging 
service center MMSC . Anyway, also in this case the result 
is carried further to the steps S33-S35. 

The several choices for the terminal MS how to decide on 

10 the delivery of the multimedia message MM are discussed 
above, and some of these are shown in Fig. 3 as 
explanatory examples. That is, in step S33 the terminal 
checks whether the result is to retrieve the multimedia 
message MM partly or completely, and if this is the case, 

15 a step S37 follows, wherein the MMSDeliverReq message is 
sent to the multimedia messaging service center MMSC. If 
the multimedia message MM shall not be retrieved, but the 
result is checked in a step S34 that it is to be 
forwarded, there follows a step S38 to send the 

20 MMSForwardReq message to the multimedia messaging service 
center MMSC. In case the result is not to forward the 
message, the process flows to step S35 to check whether 
the result is to have the multimedia message MM to be 
stored in the multimedia messaging service center MMSC. 

25 If this is true, the step S39 follows which includes the 
sending of the MMSStoreReq message to the multimedia 
messaging service center MMSC, if it is not true, the 
step S40 follows which includes the sending of the 
MMSDiscardReq message to the multimedia messaging service 

30 center MMSC, assuming that this is the result of the 
decision process. 

All of the steps S37-S40 are followed in any case by a 
step S41, in which the user profile is one more time 
35 checked, whether the user is to be notified by a proper 
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notification in a step S42 about the presence of a 
multimedia message MM and, moreover, probably about the 
performed handling of it, or not. In both cases, the flow 
is ended until another MMSNotify message will be 
5 received. 

It is mentioned, that the reply message sent by the 
terminal MS according to one of the steps S37-S40 of 
Fig. 3 is received by the multimedia messaging service 
10 center MMSC in the step S22 of Fig. 2. Further, this 
reply message contains in any way every information 
needed for the multimedia messaging service center MMSC 
to act according to the terminal originated decision on 
the delivery of the multimedia message MM. 

15 

It is noted again, that the examples depicted by Figs. 2 
and 3 are not limiting the invention, and the range of 
choices for the delivery of the multimedia message has 
been set out above in greater detail. According to the 
20 present invention, a further refinement and/or 

modification of the flow-charts of Figs. 2 and 3 can 
easily be obtained along the lines of the description as 
set out above . 

25 As a further alternative within the second embodiment, 
the signaling between the terminal and the multimedia 
messaging service center could be implemented with a 
single request-reply message pair. Stated in other words, 
the terminal could always reply to the MMSNotify message 

30 with a MMSNotif yReply message. In this case, the desired 
functionality of the terminal and the multimedia 
messaging service center can be achieved by allocating a 
control flag (e.g. in 2-bit representation) to each part 
of the multimedia message in said MMSNotif yReply message. 

35 If the value of the flag is either deliver, store, 
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forward or discard, the terminal is able to inform the 
multimedia message service center with a single reply 
message how to handle each part of the multimedia 
message . 

5 

This kind of solution would allow a more flexible 
functionality. For example, it is fully apparent that, 
according to this alternative, it would be possible to 
instruct the multimedia messaging service center with one 
10 reply message to treat each part of the multimedia 

message independent and separated from the other parts, 
so that some parts can be delivered to the terminal, some 
parts can be forwarded to an internet email address etc. 



15 However, this provides that the multimedia message is 
clearly defined in parts and that the multimedia 
messaging service center is able to handle each part 
separated. 

20 According to the second embodiment, there arise the 
following further advantages: 

The terminal capabilities and user profile information do 
not have to be maintained in the multimedia messaging 
25 service center, whereby both the storage and processing 
capacities of the multimedia messaging service center are 
not consumed, rather being left for other objects. 

Furthermore, the information does not have to be 
30 delivered each time upon predetermined conditions to keep 
the information stored in the multimedia messaging 
service center valid. Therefore, no extra signaling is 
caused between the terminal and the multimedia messaging 
service center. In conclusion, it is guaranteed that the 
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information is always up to date and no traffic 
cluttering appears due to update signaling. 

Still further, no extra amount of processing has to be 
5 done in the multimedia messaging service center. Since it 
can be expected that the structure of the multimedia 
messaging service center can be left on a less complex 
level according to the second embodiment, i.e. the 
implementation of the multimedia messaging service center 
10 becomes simpler and its performance requirements 

decrease, there might be reasons why this embodiment 
could be preferable. 

As is described above, the present invention proposes a 
15 method for delivering messages in a communication network 
consisting of at least one terminal and a messaging 
functionality, said method comprising the steps of 
receiving a message MM for said terminal MS by said 
messaging functionality MMSC; sending a notification 
20 MMSNotify about the presence of said message MM from said 
messaging functionality MMSC to said terminal MS; 
deciding by said terminal MS due to its capabilities CAP 
and current user profile UP how to handle said received 
message MM; replying by said terminal MS to the 
25 notification sent by said messaging functionality MMSC, 
therewith instructing according to the result of said 
decision step; and handling said message MM by said 
messaging functionality MMSC according to said 
instructions . 

30 

It should be understood that the above description and 
accompanying figures are only intended to illustrate the 
present invention by way of example only. The preferred 
embodiments of the present invention may thus vary within 
35 the scope of the attached claims. 
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Claims 



1. A method for delivering messages in a communication 
network consisting of at least one terminal and a 
5 messaging functionality, said method comprising the steps 
of 

submitting information concerning the capabilities 
(CAP) of the terminal (MS) and a current user profile 
(UP) thereof from said terminal (MS) to said messaging 
10 functionality (MMSC) upon the occurrence of a 
predetermined condition ; 

deciding by said messaging functionality (MMSC) 
according to said information how to handle a message 
(MM) for said terminal (MS) received by said messaging 
15 functionality (MMSC) ; and 

handling said message (MM) by said messaging 
functionality (MMSC) according to the result of said 
decision step. 

20 2. A method according to claim 1, further comprising the 
step of storing said information in said messaging 
functionality (MMSC) . 



3. A method according to claim 1, wherein 
25 the result of said decision step can at least reside in 
that said message (MM) for said terminal (MS) is 
delivered completely, partly or modified to said terminal 
(MS) , that said message (MM) is discarded, that said 
message (MM) is forwarded to another terminal, or that 
30 said message (MM) is stored in said messaging 
functionality (MMSC) . 



4. A method according to claim 1, wherein said 
predetermined condition is at least one of the following 
35 events: a login of said terminal (MS) into said network, 
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a change of connection conditions of said terminal (MS) , 
a context activation or the change of a context 
condition, a user profile (UP) creation or a user profile 
(UP) modification, a terminal originated traffic or a 
5 terminal terminated traffic, a request of said messaging 
functionality (MMSC) , a notification of said messaging 
functionality (MMSC) concerning the presence of a new 
message (MM) to said terminal (MS) , and a notification of 
said messaging functionality (MMSC) concerning the 
10 content, type and size of a new message (MM) to said 
terminal (MS) . 



5. A method according to claim 1, wherein said 
information concerning said capabilities (CAP) of said 
15 terminal (MS) comprises at least one of the following: a 
display type of said terminal (MS) , a keyboard type of 
said terminal (MS), codecs supported by said terminal 
(MS), a memory size of said terminal (MS), an electrical 
connection of said terminal (MS) to other devices, an 
external accessory attachment to said terminal (MS), or 
the current user profile (UP) . 



20 



6. A method for delivering messages in a communication 
network consisting of at least one terminal and a 
25 messaging functionality, said method comprising the steps 
of 

receiving a message (MM) for said terminal (MS) by 
said messaging functionality (MMSC) ; 

sending a notification (MMSNotify) about the 
30 presence of said message (MM) from said messaging 
functionality (MMSC) to said terminal (MS) ; 

deciding by said terminal (MS) due to its 
capabilities (CAP) and current user profile (UP) how to 
handle said received message (MM); 
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replying by said terminal (MS) to the notification 
sent by said messaging functionality (MMSC) , therewith 
instructing according to the result of said decision 
step; and 

5 handling said message (MM) by said messaging 

functionality (MMSC) according to said instructions. 

7. A method according to claim 6, wherein the result of 
said decision step can at least reside in that said 

10 message (MM) for said terminal (MS) is delivered 

completely, partly or modified to said terminal (MS) , 
that said message (MM) is discarded, that said message 
(MM) is forwarded to another terminal, or that said 
message (MM) is stored in said messaging functionality 

15 (MMSC) . 



8. A method according to claim 6, wherein said 
notification (MMSNotify) about the presence of said 
message (MM) from said messaging functionality (MMSC) to 
20 said terminal (MS) further notifies about at least 
contents, types and size of said message (MM) . 



9. A method according to claim 8, wherein said terminal 
(MS) replies to said messaging functionality (MMSC) in 

25 the course of the signaling by sending a notification 

reply message which contains a control flag for each part 
of said message (MM) , and the value of said control flag 
could be either deliver, modify, store, forward or 
discard. 

30 

10. A method according to claim 6, wherein said decision 
step comprises a request of said terminal (MS) to the 
user how to handle the message (MM) and an input by the 
user representing the result of said decision step. 



WO 00/64110 PO7EP99/02763 

22 

11. A messaging functionality device comprising 

receiving means adapted to receive messages (MM) and 

information; 

processing means adapted to process received 

information data and messages (MM) ; 
storing means; 

sending means adapted to send information and 
messages (MM) , respectively, to said terminal (MS) . 



12 . A terminal device comprising 

receiving means adapted to receive messages (MM) and 
information; 

processing means adapted to process received 
information data and messages (MM) ; 

storing means ; 

sending means adapted to send information and 
messages (MM) , respectively, to said terminal (MS) . 
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